1. Field of the Invention
This invention relates to computer systems, and more particularly to user control of priority of tasks performed by a computer system.
2. Background of the Invention
Many modern processors execute multiple tasks at once. Processors execute these tasks at varying levels of priority, with instructions of higher priority tasks being preferentially executed over instructions of lower priority tasks. In normal operation, the higher priority tasks do not require all of the instructions executed by the processor. There are sufficient instructions available to correctly execute the lower priority tasks. This means that both high priority and low priority tasks are performed correctly.
For example, a higher priority task may be a music playback program and a lower priority task may be a word processing program, both running on the same computer. The music program has a higher priority because it requires a certain rate of instructions to be executed to output the music correctly. If the music program were low priority and had to wait for instructions not used by a higher priority task, there could be pauses in the music or other problems with music playback. Such pauses would mean unacceptable playback quality. In contrast, it is acceptable for a word processing program to have a lower priority because short time periods when it pauses while waiting for processing time not used by higher priority tasks have minimal effect on the functionality of the program. A music program with repeated short pauses would be unusable, but a word processing program with those same short pauses could still function correctly.
FIG. 1 is a timing diagram 100 showing how a higher priority task and a lower priority task are executed, and a problem that can occur. Thread A is a higher priority task, the music playback program in the example above. Thread B is a lower priority task, the word processing program in the example above. In FIG. 1, at first both threads A, B are being executed. Instructions 106 for thread A are executed as needed, and any remaining processing cycles of the processor are made available for instructions 108 of thread B. Even though thread A has higher priority, it does not require all the processing cycles of the processor. The processor can also execute instructions 108 for thread B. Thus, both threads function correctly.
However, at time 110 an event occurs that causes thread A to request and use all the processing cycles of the processor. This could be caused by a malfunction or “bug” in thread A. Thus, after time 110 only instructions 106 of thread A are executed. No instructions 108 for thread B are executed; thread B is “starved” of processing cycles. This causes problems for the user. In the example above, the lower priority word processing program would no longer function. Typically, user interface functions, such as the drawing of windows on a screen, are also a lower priority. This means that it appears to the user that the word processing program, as well as the computer in general, has frozen and completely stopped functioning.
To return the computer to normal operation, the user stops the malfunctioning task from using all the instructions executed by the processor. One conventional way users stop the malfunctioning task from using all the instructions executed by the processor is to send a hardware interrupt to the processor. For example, in the Windows operating system, the user presses the “ctrl-alt-delete” keys simultaneously to send a hardware interrupt. In response to this hardware interrupt, the tasks that were running are interrupted and special software, a “task manager,” is run that presents the user with options with which to correct the problem. For example, the user may end the task that is causing the problem. By ending the task, other lower priority tasks would then be executed correctly.
However, such conventional solutions have problems. Because the hardware interrupt stops the tasks that were being executed at an arbitrary time in response to the user command, the state of the processor, related memory, and tasks being executed by the processor are unknown. In such a state, it would be easy to cause problems, such as corrupting data structures, if normal software processes were then executed. To avoid such problems, the software that runs in response to the hardware interrupt provides only limited functionality. For example, it allows the user to end the malfunctioning task. However, because of the danger of corrupting data structures and causing other problems, the software that runs in response to the hardware interrupted does not allow the user to perform many other actions that would be helpful to diagnose or correct the problem, or minimize damage from the problem. Further, the “ctrl-alt-delete” interrupt is hard-coded into the computer's BIOS and hardware, and as such cannot be reprogrammed by either the user or the applications developer to invoke other functionality.
Accordingly, it is desirable to provide a mechanism for a user to work around malfunctioning high priority tasks with more flexibility than conventional mechanisms.